Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Do It Now

If you think of something that needs to be done, do it. If you cannot do it right away, write it down or email it to yourself. Outline how you will do the work if the task is complicated. Do not assume you will remember to do it later. During the course of a large project, you will have thousands of chances to forget some small task, any one of which could prevent a bug.

If you cannot handle the task now, you will probably need to handle it later in any case. Do not ignore it hoping it will go away. If you do not have time for the task but it must be done, point it out to the project manager so someone else can handle it.

Fix It Now

It is a well-known fact that the longer a bug remains in the code, the harder it is to fix. Removing a bug is easiest when the code is fresh in your mind. If a long time has passed and you have worked on dozens of other routines since you wrote the original code, you must spend extra time reacquainting yourself with the routine before you can fix the bug.

In the meantime, other developers may have written subroutines that implicitly rely on your routine’s buggy behavior. When you fix the bug, those other routines may stop working. The other developers will need to stop what they are doing to fix them. In the worst case, still other routines will break when those routines are fixed.

If you discover a bug, fix it right away. If the bug is not in your code, tell the code’s author. Make sure the bug gets fixed as soon as possible. Do not let higher-priority tasks delay fixing the bug. There are no higher-priority tasks than removing bugs from the code. Remove bugs as quickly as possible to prevent their effects from spreading.

Test It Now

As soon as you write a routine, test it thoroughly. Execute every line of code in the debugger to make sure it does what it should. It is easiest to test code in this way when it is fresh in your mind. Do not wait until you have forgotten how the routine works.

The longer a bug remains in the code, the harder it is to find and remove. Catch the bugs right away before they make themselves comfortable and before someone else writes a routine that relies on this routine’s buggy behavior.

This does not mean testing for this routine is over forever. You still need to perform module- and system-level testing later, but you can catch a huge number of bugs simply by stepping through the code right after you write it.

Make it your goal to never let a bug slip past this test. The few minutes you spend testing now will later be repaid many times over.

If It Works, Don’t Fix It

Once you have written a routine that works, and you have tested it to make sure it works correctly, move on to something else. Do not waste endless hours puttering away at the code trying to reduce the routine’s runtime by a few percent. Later, if the routine turns out to be a performance bottleneck, you can rewrite it.

When you look at someone else’s code, or even code you wrote in the past, resist the temptation to change it. This can be particularly difficult if you are an accomplished developer reading a less-experienced programmer’s code. You may be tempted to rewrite everything you see.

You could undoubtedly improve the code, but that would defeat the purpose of having more than one person working on the project. You must admit to yourself that you cannot personally write every line of code. If someone else’s code works, leave it alone.

Review the other programmer’s code. Test it if you think it has not been properly tested. If the code has problems, ask the original author to fix them. However, if the code works as it should, leave it alone and move on to something else.

Don’t Fiddle

Leave working code alone. Do not rewrite it to clean it up, reformat it, or tighten a few loose loops here and there. Chances are your small improvements will make little difference to the complete application anyway.

Do not rewrite working code unless you have an extremely good reason to do so. Modifying code is more likely to introduce bugs than writing new code, so write some new code instead.

Even adding or removing comments can be risky. Many programmers think they do not need to completely understand a routine to change its comments. Then, while modifying the comments, they make just one or two trivial changes. If they do not understand the entire routine, there is no way they can know whether the changes will make a difference. While intending to change only comments, the programmer has broken a working routine.

Even worse, after changing only comments (and one or two things they think are inconsequential), many programmers will not retest the routine. If a bug has been introduced, it will be much harder to catch and fix later.

Many developers rewrite routines to make them more maintainable. That only makes sense when you personally have some knowledge about the routine that others who will maintain the code in the future do not have. If you wrote the routine and it is still fresh in your mind, and you are about to leave the company, and the person who is taking over for you is a junior programmer, it makes some sense to try to pass along your knowledge. In that case, try to restrict yourself to adding better comments to the code.

If someone else wrote the code, leave it alone. Rewriting it now when you do not need to will not make it any more maintainable than rewriting it later when you have a good reason to do so.

If the code isn’t broken, don’t fix it or it will soon be.

Design Before You Code

Many beginning programmers write down the purpose of a routine and a plan of attack before starting to code. They do this because they do not have the experience to know immediately what they need to do. Without at least a skeletal plan, a beginner can waste a huge amount of time typing, deleting, and retyping a single line of code until it works.

More experienced programmers sometimes grow lazy and start coding without any clear strategy. They just pull up an editor window and start typing.

Sometimes this works, but this strategy allows the developer to begin writing code without a complete plan for where it is going. As the code develops, the later code may conflict with code entered earlier. A really good programmer will notice the problem and go back to fix it. A less-experienced programmer may not notice the problem, particularly if the routine is long. The result may be some very subtle bugs.

Think first, then code. Do not touch finger to keyboard until you have a clear plan for the routine.

One fast and easy way to integrate design and coding is to generate the design as a series of comments. Start by writing a description of the problem. This should be no more than one or two sentences. If you cannot clearly state the routine’s purpose in one sentence, it probably does not perform a single coherent task. In that case, you should break it into smaller routines, each having a well-defined purpose.

A sorting routine might have this purpose:

Sort an array of numbers.

Next, write a general description of the solution. Include statements to validate parameters and verify the result. This description should indicate in English how the routine will perform its duties.

The description should not involve any Visual Basic commands. It should be nonspecific enough that you could use it to implement the routine in another language like Delphi or C++.

Sort an array of numbers.
    Validate the parameters.

    For each position in the array:
        Find the smallest item not yet positioned:
        Swap the smallest item into the position we are considering.

     Verify the solution.